Multi-cloud active mesh network system and method

ABSTRACT

According to one embodiment, a network system features a first virtual private cloud (VPC) network and a second VPC network. The first VPC network includes a first plurality of gateways. Each gateway of the first plurality of gateways is in communications with other gateways. Similarly, a second VPC network includes a second plurality of gateways. Each of the second plurality of gateways is communicatively coupled to the each of the first plurality of gateways to support data exchanges between resources deployed in different public cloud networks.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of U.S. patent applicationSer. No. 17/079,399 filed Oct. 23, 2020, which claims the benefit ofpriority on U.S. Provisional Patent Application No. 62/982,679 filedFeb. 27, 2020, the entire contents of both of which are incorporated byreference herein.

FIELD

Embodiments of the disclosure relate to the field of networking. Morespecifically, one embodiment of the disclosure relates to aload-balanced, full-mesh network architecture configured to mitigatecommunication disruptions, especially between virtual private clouds(VPCs) within different public cloud networks.

GENERAL BACKGROUND

Over the past few years, cloud computing has provided an Infrastructureas a Service (IaaS), where resources are provided as part of a cloudcomputing platform (e.g., public cloud network) and made accessible totenants as a service. One of these services allows tenants to runsoftware components (e.g., virtual machines instances such as virtualservers) residing within the cloud computing platform. Hence, themigration of software functionality into cloud computing platforms hasled to greater usage of virtual private cloud networks (VPCs).

A virtual private cloud network (VPC) is an on-demand, configurable poolof shared resources, which are allocated within the cloud computingplatform and provide a certain level of isolation between the differentorganizations or other entities (hereinafter, “users”) using theresources. The isolation between one VPC user from other users of thesame cloud computing platform may be achieved through allocation of aprivate Internet Protocol (IP) subnet and a virtual communicationconstruct (e.g., virtual local area network “VLAN” or other protectedcommunications) per user. For example, Amazon® Web Services (AWS®)provides for the purchase of Amazon® Elastic Compute Cloud (EC2)services with dedicated data processing capabilities for a particularuser.

Currently, certain cloud computing platforms provide connectivitybetween VPCs. This connectivity, sometimes referred to as “peering,”constitutes an establishment of peer-to-peer communications betweenseparate VPCs for the purpose of routing data traffic as requested.These peer-to-peer communications include a primary communication linkand a high availability (HA) communication link. The HA communicationlink is operational in response to a “failover” condition. Morespecifically, the communications between a gateway deployed within a VPCand either (i) a gateway of another VPC or (ii) an on-premises computingdevice such as a router controlling communications within an on-premisesnetwork are accomplished by the primary communication link placed in an“active” state. The HA communication link is initially set to a“standby” (inactive) state, but is switched to an “active” state whenthe primary communication link fails. However, this VPC “failover”communication scheme suffers from a number of disadvantages.

One disadvantage associated with the conventional VPC failovercommunication scheme is that it requires deployment of complex failoverlogic within the controller to manage operability of the public cloudnetwork. For example, the failover logic would need to continuouslytrack the current state of the primary communication link and would needto conduct an update of a gateway routing table for the cloud computingnetwork in response to failure of the primary communication link.Additionally, in response to failure of both the primary and HAcommunication links, the failover logic would need to reprogram the VPCrouting table. The VPC routing table is relied upon for determiningwhich gateway is targeted to receive downloaded data while the gatewayrouting table is relied upon for determining which communication link isused for transmission of the downloaded data. Another disadvantage withthe active-standby failover scheme is the inefficient use of resourcesallocated for the standby communication link. These resources are neverused until a failover event happens.

The updating of both of these routing tables is time consuming anddisruptive to ongoing communications, especially the reprogramming ofthe VPC routing table. The convergence (stabilization) of the networkand avoidance of disruption of data communications within or to thepublic cloud is necessary as more companies migrate their networkingoperations to the cloud.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example and notby way of limitation in the figures of the accompanying drawings, inwhich like references indicate similar elements and in which:

FIG. 1 is a diagram of an exemplary embodiment of a public cloudcomputing platform implemented as a load-balanced, full-mesh networkfeaturing multiple virtual private cloud networks that collectivelysupport communications between multiple instances within a private cloudnetwork and an on-premises network;

FIGS. 2A-2B are exemplary embodiments of a gateway routing tableprogrammed to represent IPSec tunnel supported by a gateway of a firstvirtual private cloud network of the load-balanced, full-mesh network.

FIGS. 2C-2D are exemplary embodiments of a transit gateway routing tableprogrammed to represent IPSec tunnel supported by a transit gateway of asecond virtual private cloud network of the load-balanced, full-meshnetwork.

FIG. 3 is an exemplary illustration of a logical representation of agateway deployed within the virtual private cloud network of FIG. 1.

FIG. 4 is a second exemplary embodiment of a multi-public cloudcomputing platform, including the full-mesh network configured tomitigate the disruption of communications between four (4) virtualprivate cloud networks that are deployed within two or more public cloudnetworks.

FIG. 5 is a flowchart of an exemplary embodiment of the operability ofthe public cloud computing platform of FIG. 1 in supportingcommunications between multiple virtual private cloud networks withoutreliance of changes to the VPC routing table.

FIG. 6A is a diagram of an exemplary embodiment of the public cloudcomputing platform supporting communications between multiple virtualprivate cloud networks over a first communication link (IPSec tunnel) inresponse to failure of a second communication link (IPSec tunnel)formerly utilized by the virtual private cloud networks.

FIG. 6B is a diagram of an exemplary embodiment of the public cloudcomputing platform of FIG. 6A supporting communications between multiplevirtual cloud networks over the second communication link in response tofailure of the first communication link.

FIG. 6C is a diagram of an exemplary embodiment of the public cloudcomputing platform of FIG. 6A supporting communications between multiplevirtual private cloud networks over a secondary tunnel in response tofailure of the first and second communication links.

DETAILED DESCRIPTION

Embodiments of a system and method for establishing a load-balanced,full-mesh network over multiple public cloud networks, where thefull-mesh network mitigates disruption of communications directed to orfrom virtual private cloud networks (VPCs) due to communication linkfailures. The full-mesh network may be accomplished by establishing (i)a first cloud-based networking infrastructure operating as a firstvirtual private cloud network (hereinafter, “spoke VPC”) and (ii) asecond cloud-based networking infrastructure operating as a secondvirtual private cloud network (hereinafter, “transit VPC”). Thesetransit VPCs may be deployed within different public cloud networks,where transit VPCs deployed with Microsoft® Azure® are sometimesreferred to as virtual networks or “VNets”.

The spoke VPC includes a set of (e.g., two or more) gateways(hereinafter, “spoke gateways”), which are communicatively coupled toone or more instances (e.g., cloud instances associated with aparticular subnet or particular subnets as described below) and a set ofgateways deployed within the transit VPC (hereinafter, “transitgateways”). Each of the spoke gateways and transit gateways may beaccessed in accordance with a unique Classless Inter-Domain Routing(CIDR) routing address to propagate messages over the network.

Besides communicatively coupled to the set of spoke gateways, the set oftransit gateways may be communicatively coupled to one or more computingdevices deployed within an on-premises network (hereinafter, “on-premcomputing devices”). Herein, the transit VPC may be configured to bedeployed within the same public cloud network as the set of spokegateways or may be deployed in a different public cloud network. Thetransit VPC is configured to control the propagation of data trafficbetween the spoke VPC and the on-premises network while the spoke VPC isconfigured to control the propagation of data traffic between instancesmaintained within the spoke VPC and the transit VPC.

According to one embodiment of the disclosure, the first cloud-basednetworking infrastructure features a one-to-many communication linkdeployment (e.g., criss-cross peering), where each spoke gatewaysupports multiple, active peer-to-peer communication links to differenttransit gateways and each transit gateway supports multiple, activepeer-to-peer communication links to different spoke gateways as well asan active peer-to-peer communication link to each on-prem computingdevice. According to one embodiment of the disclosure, the peer-to-peercommunication links may constitute cryptographically secure tunnels,such as tunnels operating in accordance with a secure network protocol.One example of a secure network protocol may include, but is not limitedor restricted to Internet Protocol Security (IPSec). Hence, for claritysake, these peer-to-peer communication links may be referred to as“IPSec tunnels.”

Herein, the deployment of full-mesh peering in lieu of primary/HAcommunication links utilized in conventional cloud computing platformsprovides a number of technological advantages. For example, thefull-mesh peering architecture is configured to avoid intensivemonitoring of routing tables relied upon by a gateway (referred to as a“gateway routing table”) for determining which IPSec tunnel is used inthe transmission of data, especially for a tunnel state change. Toachieve load-balancing, all of the IPSec tunnels directed to the transitgateways are set to identical, equal cost multi-path (ECMP) routingparameters, namely identical routing weights and ECMP metrics asdescribed below. Alternatively, according to another embodiment of thedisclosure, loading balancing is not based on ECMP; rather, loadbalancing is achieved through an assignment of weights such thatdifferent tunnels may be assigned with different weights, based on oneor a combination of factors such as bandwidth, preference, or the like.

Herein, when an IPSec tunnel fails, the gateway updates its gatewayrouting table autonomously by disabling (bring down) a tunnel interface(e.g., virtual tunnel interface) corresponding to the failed IPSectunnel without reliance on activity by a controller that managesoperability of the full-mesh network. As a result, the gateway precludesmessages from being routed through the failed IPSec tunnel to mitigatedata transmission loss. Instead, the messages are routed through aselected active IPSec tunnel, which may be reassigned to communicationwith all or some of the instances within a particular instance subnet.In response to the IPSec tunnel becoming operational (i.e., the IPSectunnel goes up), the gateway will bring up the corresponding tunnelinterface and recover the routing path if removed from the gatewayrouting table (e.g., routing path removed when all of the IPSec tunnelsto a particular destination becoming disabled).

Additionally, the full-mesh network provides another technologicaladvantage by avoiding time intensive reprogramming of a virtual privatecloud (VPC) routing table relied upon for determining a routing pathbetween an identified source and destination. This may be accomplishedby establishing one or more secondary tunnels for each routing path,where the secondary tunnel provides an alternative routing path via agateway residing within the same VPC (e.g., gateways within the spokeVPC, gateways within the transit VPC, etc.). Each secondary tunnelsupports the transmission of data through the alternative routing pathwhen all of the IPSEC tunnels from a particular gateway have failed.Hence, secondary tunnels enable another gateway to operate as anintermediary device to support continued communications from theparticular gateway with a remote peer destination (e.g., cloud instance,on-prem computing device, etc.). Each of the secondary tunnels may beconfigured in accordance with Generic Routing Encapsulation (GRE) tunnelprotocol to secure communications between gateways within the same VPC.However, it is contemplated that another tunneling protocol, such as anyIP routable tunnel based on Private IP addressing, inclusive of IPSec,may be used other than GRE.

Routing path selection via the gateways within the VPCs may beaccomplished through an equal cost multi-path (ECMP) routing strategy,namely next-hop message forwarding to a single destination can occurover multiple “best” paths that are determined in accordance with anassigned ECMP metric. Hence, the IPSec tunnels associated with a gateway(e.g., spoke gateway or transit gateway) are assigned equivalent ECMPmetrics that are lower than the ECMP metrics assigned to any of thesecondary (GRE) tunnels.

Besides the network architecture per se, the operability (method)performed by the system for establishing the load-balanced, full-meshnetwork to mitigate disruption of communications directed to or from theVPCs is described. Herein, a controller managing operability of one ormore public cloud networks configures one or more spoke VPCs bysegregating cloud instances within each spoke VPC to particular subnets.A “subnet” is a segment of a VPC's IP address range designated to groupresources (e.g., managed software instances each directed to particularfunctionality) based on security and operational needs. Hence, eachinstance subnet established within a spoke VPC may be a collection ofinstances for that spoke VPC that are selected to communicate with aselected spoke gateway residing in the spoke VPC.

Thereafter, the controller may be configured to collect VPC information(e.g., VPC subnet allocations, VPC routing tables and their associationwith subnets) and/or configure a VPC routing table associated with eachspoke gateway to establish communication links (e.g., logicalconnections) between a certain spoke gateway and cloud instancesassociated with a particular instance subnet. The VPC routing table isprogrammed to support communication links between different sources anddestinations, such as an on-prem computing devices, a cloud instancewithin a particular instance subnet or the like.

Besides the VPC routing tables for each of the spoke gateways, thecontroller may be adapted to configure gateway routing tables for eachof the gateways within the VPCs of the full-mesh network. Morespecifically, according to one embodiment of the disclosure, thecontroller may be configured to initially program gateway routing tablesfor both spoke gateways residing within the spoke VPC(s) and transitgateways residing within the transit VPC(s). The gateway routing tablesare relied upon by the gateways for determining which tunnels to use forpropagating data traffic (e.g., messages) towards a destination (e.g.,virtual tunnel interface for a destination cloud instance or computingdevice). For this embodiment of the disclosure, the gateway routingtables includes both IPSec tunnels and secondary (e.g., GRE) tunnelsbetween gateways within the same VPC to be used in the event that all ofthe IPSec tunnels have failed.

The gateway routing tables are accessible to their correspondinggateways, and are updated by these gateways. For example, in response toa failed IPSec tunnel (e.g., change in tunnel state), the gatewayassociated with the failed IPSec tunnel disables its virtual tunnelinterface (VTI). By disabling the VTI associated with the failed IPSectunnel, further data transmissions over the failed IPSec tunnel isprevented. The disabling of the VTI may be conducted by a gateway (e.g.,spoke gateway or transit gateway) without further operability by thecontroller.

Logic within the gateway detects reversion in the tunnel state (e.g.,IPSec tunnel is now active) and, if so, the gateway re-activates thetunnel interface (e.g., remove “disabled” tag and/or resets “active”tag) or recovers the routing path associated with the previously failedIPSec tunnel if removed from the gateway routing table. This recovery ofthe routing path may be accomplished by accessing a data store (e.g.,database) associated with the gateway that maintains routing pathsavailable to that gateway, even failed (disabled) IPSec tunnels.

Based on the foregoing, the reduction in VPC routing table programmingis made available through the configuration of the secondary (e.g., GRE)tunnels. End to end load balance is achieved through the networkarchitecture by using of two technics at different stages. Firstly, fromVPC instances to spoke gateway, each VPC instance is under a routingsubnet. The subnet is associated with a routing table. The routing tableroute forward data traffic from the instance to a spoke gateway. Trafficfrom difference source instances of different subnet (routing table) aresent to different spoke gateways, instead of all source instancessending traffic to one spoke gateway in active-standby scheme. Secondly,between spoke gateway and transit gateway, or transit gateway toon-premises routers, this may be based on analytics conducted on a5-tuple of a message (e.g., source IP address; source port; destinationIP address; destination port; destination protocol), which is routedfrom between the spoke gateway and transit gateway or between thetransit gateway and on-premises routes. The analytics may be a one-wayhash operation in which the results (or a portion of the results) areused to select a particular ECMP link in the routing table to transmitof the data traffic.

Further details of the logic associated with one embodiment of theload-balanced, full-mesh network system architecture are describedbelow:

Instance Subnets: Multiple instance subnets may be generated in a spokeVPC so that instances forming a particular instance subnet are forwardedto a selected spoke gateway.

VPC routing table(s): A VPC routing table may be used to associate spokegateways within each VPC with one or more different instance subnets.Load balancing is achieved by implementing the full-mesh network system,where identical, equal cost multi-path (ECMP) routing parameters areassigned to each of the gateways and a secondary tunnel is establishedbetween each peer gateway pair within the same VPC. Therefore, the VPCroutable table requires no programming unless the gateway becomesdisabled (i.e., goes down), where the VPC routing table may be remappedbased on the results of a 5-tuple analytics mapped to the remainder ofthe active gateways within the VPC.

Gateways: Multiple gateways are deployed in a VPC, where each gateway islogic that is configured to control the flow of data traffic frominstances of the VPC to one or more remote sites or cloud networks alongwith traffic from/to computing devices within on-premises networks thatmay process data received from the instances. Having similararchitectures, the gateways may be identified differently based on theirlocation/operability within a public cloud network platform. The “spoke”gateways are configured to interact with targeted instances while“transit” gateways are configured to further assist in the propagationof data traffic (e.g., one or more messages) directed to a spoke gatewaywithin a spoke VPC or a computing device within the on-premises network.

IPSec tunnels: Secure peer-to-peer communication links establishedbetween gateways of neighboring VPCs or between gateways of a VPC and arouter of an on-premises network. The peer-to-peer communication linksare secured through a secure network protocol suite referred to as“Internet Protocol Security” (IPSec). With respect to the full-meshnetwork deployment, as an illustrative example, where a spoke VPC has“M” gateways and a neighboring (transit) VPC has N gateways, M×N IPSectunnels are created between the spoke VPC and the transit VPC to formthe full-mesh network. These IPSec tunnels are represented in gatewaysby virtual tunnel interface (VTI) and the tunnel states are representedby VTI states.

Gateway routing: In gateway routing table, routing paths between thegateway and an IP addressable destination to which the tunnel terminates(e.g., another gateway, on-prem computing device, etc.), identified by avirtual tunnel interface (VTI) for example, are programmed with ECMProuting parameters, namely identical routing weights and ECMP metrics.Given consistent ECMP metrics are assigned to the IPSec tunnels, theselected routing path towards the remote network may be based onanalytics conducted on certain information associated with data traffic(e.g., 5-tuple). These analytics may include conducting a one-way hashoperation on the 5-tuple information where a portion of the hash valuemay be used to identify the selected IPSec tunnel. If any of the IPSectunnels state is changed or disabled (or re-activated), thecorresponding VTI may be removed (or added) from consideration as totermination points for the selected routing path.

Secondary tunnels: Each of the gateways in the same VPC may beconfigured to create secondary (backup) communication links (e.g., GREtunnels) towards all other gateways within that VPC, also represented byVTIs. For example, with respect to a VPC including M gateways, eachgateway will have M−1 secondary communication links. Herein, thesesecondary communication links are assigned with higher metric valueswithin the gateway routing table than communication links (e.g., IPSectunnels) pointing to a remote peer gateway. Therefore, according to oneembodiment of the disclosure, a secondary communication link (e.g., GREtunnel) will not forward traffic until all of the IPSec tunnels for thatparticular gateway have become disabled (gone down).

I. Terminology

In the following description, certain terminology is used to describefeatures of the invention. In certain situations, the terms “logic” and“computing device” is representative of hardware, software or acombination thereof, which is configured to perform one or morefunctions. As hardware, the logic (or device) may include circuitryhaving data processing or storage functionality. Examples of suchcircuitry may include, but are not limited or restricted to amicroprocessor, one or more processor cores, a programmable gate array,a microcontroller, an application specific integrated circuit, wirelessreceiver, transmitter and/or transceiver circuitry, semiconductormemory, or combinatorial logic.

Alternatively, or in combination with the hardware circuitry describedabove, the logic (or computing device) may be software in the form ofone or more software modules. The software module(s) may include anexecutable application, an application programming interface (API), asubroutine, a function, a procedure, an applet, a servlet, a routine,source code, a shared library/dynamic load library, or one or moreinstructions. The software module(s) may be stored in any type of asuitable non-transitory storage medium, or transitory storage medium(e.g., electrical, optical, acoustical or other form of propagatedsignals such as carrier waves, infrared signals, or digital signals).Examples of non-transitory storage medium may include, but are notlimited or restricted to a programmable circuit; a semiconductor memory;non-persistent storage such as volatile memory (e.g., any type of randomaccess memory “RAM”); persistent storage such as non-volatile memory(e.g., read-only memory “ROM”, power-backed RAM, flash memory,phase-change memory, etc.), a solid-state drive, hard disk drive, anoptical disc drive, or a portable memory device. As software, the logicmay operate as firmware stored in persistent storage.

The term “computerized” generally represents that any correspondingoperations are conducted by hardware in combination with software.

The term “gateway” may be construed as a virtual or physical logic. Forinstance, as an illustrative example, the gateway may correspond tovirtual logic in the form of a software component that perform routingof data. As an illustrative example, the gateway may constitute avirtual machine (VM)-based data routing component that is assigned aPrivate IP address within an IP address range associated with a VPCincluding the gateway. As another illustrative embodiment, the gatewaymay constitute a virtual network (VNet). The gateway allows CloudService Providers (CSPs) and enterprises to enable datacenter and cloudnetwork traffic routing between virtual and physical networks, includinga public network (e.g., Internet). Alternatively, in some embodiments,the gateway may correspond to physical logic, such as an electronicdevice that is communicatively coupled to the network and assigned thehardware (MAC) address and IP address.

The term “cloud-based networking infrastructure” generally refers to acombination of software instances generated based on execution ofcertain software by hardware associated with the public cloud network.Each software instance may constitute a virtual network resourceassociated with the public cloud network, such as a switch, server orthe like.

The term “message” generally refers to information in a prescribedformat and transmitted in accordance with a suitable delivery protocol.Hence, each message may be in the form of one or more packets, frames,or any other series of bits having the prescribed format.

The term “transmission medium” may be construed as a physical or logicalcommunication path between two or more electronic devices. For instance,as a physical communication path, wired and/or wireless interconnects inthe form of electrical wiring, optical fiber, cable, bus trace, or awireless channel using infrared, radio frequency (RF), may be used.

Finally, the terms “or” and “and/or” as used herein are to beinterpreted as inclusive or meaning any one or any combination. As anexample, “A, B or C” or “A, B and/or C” mean “any of the following: A;B; C; A and B; A and C; B and C; A, B and C.” An exception to thisdefinition will occur only when a combination of elements, functions,steps or acts are in some way inherently mutually exclusive.

As this invention is susceptible to embodiments of many different forms,it is intended that the present disclosure is to be considered as anexample of the principles of the invention and not intended to limit theinvention to the specific embodiments shown and described.

II. General System Architecture

Referring to FIG. 1, a first exemplary embodiment of a multi-cloudcomputing platform 100 implemented with a load-balanced, full-meshnetwork 110, which supports reliable communications between one or moreinstances of a virtual private cloud network (VPC) and one or morecomputing devices 180 deployed within an on-premises network 190, isshown. According to this embodiment of the disclosure, the full-meshnetwork 110 is configured to mitigate the disruption of communicationsbetween at least a first virtual private cloud network (hereinafter,“spoke VPC”) 120 and a second virtual public cloud network (hereinafter,“transit VPC”) 130 within the multi-cloud computing platform 100 due tocommunication link failures. Although two VPCs 120 and 130 areillustrated in FIG. 1 for clarity sake, it is contemplated that multiple“spoke” VPCs and multiple “transit” VPCs may formulate the construct ofthe full-mesh network 110 as shown in FIG. 4. Also, the VPCs 120 and 130may be deployed within the same public cloud network or different publiccloud networks.

As shown, the spoke VPC 120 is configured with multiple VPC subnetworks145 (hereinafter, “subnets”), where each of these subnets 145 includesdifferent cloud instances. Each of the instance subnets 145 ₁ . . . , or145 _(P) (P≥2) is configured, in accordance with a VPC routing table150, to exchange data traffic with a selected gateway of a set of (e.g.,two or more) gateways 125 ₁-125 _(M) (M≥2) maintained in the spoke VPC120. Herein, these gateways 125 ₁-125 _(M) are referred to as “spokegateways” 125 ₁-125 _(M). More specifically, a controller 160 for thefull-mesh network 110 is configured to manage communication linksbetween the instance subnets 145 ₁-145 _(P) and the set of spokegateways 125 ₁-125 _(M) as represented by the VPC routing table 150,which is initially programmed to identify which spoke gateway 125 ₁ . .. or 125 _(M) is responsible for interacting with one or more instancesubnets 145 ₁ . . . , or 145 _(P) (e.g., to receive message(s), forwardmessage(s), etc.).

Referring still to FIG. 1, according to one embodiment of thedisclosure, the full-mesh network 110 may be accomplished by peering theset of spoke gateways 125 ₁-125 _(M) deployed within the spoke VPC 120to a set of gateways 135 ₁-135 _(N) deployed within the transit VPC 130,which may be referred to as “transit gateways” 135 ₁-135 _(N) (N≥2). Asease of illustration, the set of spoke gateways 125 ₁-125 _(M) isrepresented as a first spoke gateway 125 ₁ and a second spoke gateway125 ₂, although three or more spoke gateways may be deployed within thespoke VPC 120. Similarly, the set of transit gateways 135 ₁-135 _(N) isrepresented by a first transit gateway 135 ₁ and a second transitgateway 135 ₂, although three or more transit gateways may be deployedwithin the transit VPC 130.

The spoke gateways 125 ₁-125 _(M) are configured for communications withtransit gateways 135 ₁-135 _(N) via peer-to-peer communication links 127₁₁-127 _(MN). In particular, each spoke gateway 125 _(i) (1≤i≤M) iscommunicatively coupled to each of the transit gateways 135 ₁-135 _(N)via multiple, active peer-to-peer communication links 127 _(i1)-127_(iN). Similarly, each transit gateway 135 _(j) (1≤j≤N) iscommunicatively coupled to each of the spoke gateways 125 ₁-125 _(M) viamultiple, active peer-to-peer communication links 127 _(1j)-127 _(Mj).The peer-to-peer communication links 127 ₁₁-127 _(MN) may constitutecryptographically secure tunnels, such as tunnels operating inaccordance with a secure network protocol. One example of a securenetwork protocol may include, but is not limited or restricted toInternet Protocol Security (IPSec). Hence, the VPC-to-VPC tunnels may bereferred to as “IPSec tunnels.”

In general terms, for the full-mesh network 110 that features the spokeVPC 120 including “M” spoke gateways and the neighboring transit VPC 130including “N” transit gateways, M×N IPSec tunnels 127 ₁₁-127 _(MN) arecreated between the spoke VPC 120 and the transit VPC 130. The IPSectunnels 127 ₁₁-127 _(MN) may be established and maintained throughgateway routing tables 170 ₁-170 _(M) dedicated to each of the spokegateways 125 ₁-125 _(M), respectively. For example, a first gatewayrouting table 170 ₁ determines which IPSec tunnel 127 ₁₁-127 _(1N) foruse in forwarding a message from one of the cloud instances 140 assignedto the first gateway 125 ₁ to a destination instance (not shown)reachable via one of the on-prem computing device(s) 180.

As an illustrative example, as shown specifically in FIG. 1, the firstspoke gateway 125 ₁ is communicatively coupled to both the first transitgateway 135 ₁ via IPSec tunnel 127 ₁₁ and the second transit gateway 135₂ via IPSec tunnel 127 ₁₂. Similarly, the second spoke gateway 125 ₂ iscommunicatively coupled to both the first transit gateway 135 ₁ viaIPSec tunnel 127 ₂₁ and the second transit gateway 135 ₂ via IPSectunnel 127 ₂₂. For this architecture, each spoke gateway 125 ₁ and 125 ₂is communicatively coupled to each of the transit gateways 135 ₁ and 135₂ via multiple, active peer-to-peer communication links 127 ₁₁, 127 ₁₂,127 ₂₁ and 127 ₂₂. The management of the IPSec tunnels 127 ₁₁-127 ₁₂ and127 ₂₁-127 ₂₂ may be accomplished through gateway routing tables 170₁-170 ₂ and 175 ₁-175 ₂ maintained by each of the respective gateways125 ₁-125 ₂ and 135 ₁-135 ₂, as described below.

Referring now to FIGS. 2A-2B, an exemplary embodiment of a portion ofthe first spoke gateway routing table 170 ₁ programmed to representIPSec tunnels 127 ₁₁-127 ₁₂ supported by the first spoke gateway 170 ₁of the spoke VPC 120 is shown. Herein, each IPSec tunnel 127 ₁₁ or 127₁₂ may be represented by a corresponding virtual tunnel interface (VTI)200 ₁ or 200 ₂ and a state of each IPSec tunnel 127 ₁₁ or 127 ₁₂ may berepresented by a corresponding virtual tunnel interface (VTI) state 210₁ or 210 ₂, respectively. No identification of link status (e.g.,“linkdown”) identifies that the link is active. Selection of the IPSectunnel 127 ₁₁-127 ₁₂ to support communications from the first spokegateway 125 ₁ toward the on-premises network 190 may be accomplishedthrough ECMP routing. As a result, each IPSec tunnel 127 ₁₁-127 ₁₂,selected to support message transmissions from the first spoke gateway120 ₁, is assigned an equal ECMP metric (metric=0) 220, which is lessthan the ECMP metric 230 (metric=200) assigned to the secondary (GRE)tunnels (e.g., GRE tunnel 129 ₁). It is contemplated that, while theIPSec tunnels 127 ₁₁-127 ₁₂ may be assigned identical ECMP metrics(metric=0) for load balancing, the GRE tunnel(s) may be assigneddifferent ECMP metrics to prioritize the GRE tunnels from the firstspoke gateway 120 ₁ upon failure of IPSec tunnel 127 ₁₁-127 ₁₂ shown inFIG. 1.

Referring back to FIG. 1, each transit gateway 135 _(j) (1≤j≤N) supportsmultiple active peer-to-peer communication links with each of theon-prem computing device(s) 180 (e.g., on-prem computing devices 180 ₁and 180 ₂). Hence, where the transit VPC 130 includes “N” transitgateways in communications with a plurality of on-prem computing devices180 ₁ and 180 ₂, N×2 IPSec tunnels 137 ₁₁-137 ₁₂ . . . and 137 _(N1)-137_(N2) are created between the transit VPC 130 and the on-premisesnetwork 190. Similarly, the IPSec tunnels 137 ₁₁-137 _(N2) may beestablished and maintained through transit gateway routing tables 175₁-175 _(N) dedicated to each of the transit gateways 135 ₁-135 _(N),respectively.

As an illustrative example, a first transit gateway routing table 175 ₁determines which IPSec tunnel 137 ₁₁-137 ₁₂ for use in forwarding amessage received from the spoke VPC 120 and directed to the destinationinstance reachable via one of the on-prem computing devices 180 ₁ and180 ₂. As shown in FIGS. 2C-2D, the first transit gateway routing table175 ₁ may be programmed to represent each IPSec tunnel 137 ₁₁-137 ₁₂ bya corresponding virtual tunnel interface (VTI) 250 ₁-250 ₂ and a stateof each of the IPSec tunnel 137 ₁₁-137 ₁₂ may be represented by acorresponding virtual tunnel interface (VTI) state 260 ₁-260 ₂. The VTIstate 260 ₁-260 ₂ and with the ECMP metrics 270 ₁-270 ₂ are used tocontrol selection in the use of IPSec tunnels 137 ₁₁-137 ₁₂ givenwhether these IPSec tunnels 137 ₁₁-137 ₁₂ are active or disabled.

Additionally, the full-mesh network 110 provides another technologicaladvantage by establishing more reliable communications by configuringeach of the gateways 125 ₁-125 _(M) and 135 ₁-135 _(N) with secondarytunnels to support data traffic when all IPSEC tunnels for a particulargateway have failed. As an illustrative example, as shown in FIG. 1, thefirst spoke gateway 125 ₁ deployed within the spoke VPC 120 establishesa secondary tunnel 129 ₁ with the second spoke gateway 125 ₂. Accordingto one embodiment of the disclosure, each of the secondary tunnels(e.g., secondary tunnel 129 ₁) may be configured in accordance withGeneric Routing Encapsulation (GRE) tunnel protocol to securecommunications between the spoke gateways 125 ₁-125 ₂ within the spokeVPC 120 and the transit gateways 135 ₁-135 ₂ within the transit VPC 130.However, it is contemplated that another tunneling protocol, such as anyIP routable tunnel reliance on Private IP addressing) may be used otherthan GRE.

Herein, the GRE tunnel formation among the spoke gateways 125 ₁-125 _(M)(M≥2) within the spoke VPC 120 is described in detail, give the GREtunnel formation for the transit gateways 135 ₁-135 _(N) within thetransit VPC 130 is consistent. In general, the spoke gateways 125 ₁-125_(M) are configured with GRE tunnels towards all other gateways in thespoke VPC 120, where the GRE tunnels may be maintained within thegateway routing tables 170 ₁-170 _(M) and terminated by VTIs associatedwith the corresponding gateways. For this embodiment, for the spoke VPC120, the first spoke gateway 125 ₁ would be configured with “M−1” backupGRE tunnels such as GRE tunnel 129 ₁₂ established between the firstspoke gateway 125 ₁ and the second spoke gateway 125 ₂. Similarly, “M−2”GRE tunnels may be established between the second spoke gateway 125 ₂and any of the remaining gateways 125 ₃-125 _(M) within the spoke VPC120. As shown, the first spoke gateway 125 ₁ is configured with GREtunnel 129 ₁₂, which establishes secondary communications with thesecond spoke gateway 125 ₂.

The GRE tunnels may be programmed with different ECMP metrics todesignate an order of selection in case any GRE tunnels fail due tofailure of the assigned gateway itself. Also, the ECMP metricsassociated with the GRE tunnels are set with a higher ECMP metric thanECMP metrics associated with any of the IPSec tunnels so that the GRErouting is selected if routing via any IPSec tunnel is not available.Hence, as shown, none of the gateways 125 ₁-125 ₂ will forward datatraffic via the GRE tunnels 129 ₁₂ until all IPSEC tunnels towardsremote peers are down (disabled).

Referring still to FIG. 1, each of the on-prem computing devices 180 ₁and 180 ₂ operates as a network router by propagating data traffic(e.g., one or more messages) originating from one of the cloud instances140 through multiple VPCs forming the full-mesh network 110. Uponreceipt of the message(s), using a local routing table, the targetedon-prem computing device (e.g., device 180 ₁) forwards the message(s) tothe destination instance(s).

Referring to FIG. 3, an exemplary illustration of a logicalrepresentation of a gateway 300 (e.g., first spoke gateway 125 ₁)deployed in a virtual private cloud network of FIG. 1 is shown. In oneembodiment, the gateway 300 may correspond to logic that provides alogical connection between a source 310 and a destination 320. Forexample, the source 310 may correspond to a user (on-prem computingdevice), resource within a VPC (e.g., cloud instance), or anothergateway that supports connectivity with the destination 320, asreferenced by a first VTI 315. Herein, in this example, the destination320 may correspond to a cloud instance (when the source 310 is a user orgateway), a user (when the source 310 is a cloud interface or agateway), or a gateway (when the source 310 is a user, cloud interfaceor another gateway), as referenced by a second VTI 325. As represented,the gateway 300 may support logical connections with one or more sources310 and/or one or more destinations 320.

The gateway 300 may be configured with routing logic 350 and a datastore 360. As shown in FIG. 3, the data store 360 may include a gatewayrouting table 370 (e.g., gateway routing table 170 ₁ where the gateway300 corresponds to the first spoke gateway 125 ₁) and a route database380. The gateway routing table 370 is referenced by the routing logic350 in determining which communication link is used for transmission ofthe data received from the source 310 for routing towards thedestination 320. The routing database 380 is configured to retainrouting paths 390 for retrieval when a disabled routing path is removedfrom the gateway routing table 370.

As an optional component, the gateway 300 may include NAT logic 395which, when executed, is configured to perform translation of the IPaddresses for data packets transmitted between the spoke VPC 120 and thetransit VPC 130. For example, in the Internet gateway 300, the NAT logic395 may create a destination NAT entry to translate a private IP addressassociated with the source 310 residing within the spoke VPC 120 to aprivate IP address utilized by the transit VPC 130 in which thedestination 320 is located. Similarly, an inverse translation isconducted where the private IP address associated with the transit VPC130 may be returned back into the private IP address associated with thespoke VPC 120.

Referring now to FIG. 4, a second exemplary embodiment of a multi-cloudcomputing platform 400, including the full-mesh network 110 configuredto mitigate the disruption of communications between a plurality of VPCs410, 420, 430 and 440, is shown. The first VPC 410 includes a first setof spoke gateways 415 operating within a selected geographic regionsupported by a first public cloud network 402 (e.g., Amazon® WebServices “AWS”). The second VPC 420 includes a second set of spokegateways 420, where these spoke gateways 420 may correspond to logic,sometimes referred to as “virtual networks” (VNets). The second set ofspoke gateways (Vnets) 420 operates within the same or a differentgeographic region as the first VPC 410 and is deployed within a secondpublic cloud network 404 (e.g., Microsoft® Azure®) different than thefirst public cloud network 402.

Additionally, as shown in FIG. 4, the third VPC 430 includes a first setof transit gateways 435 operating within the first public cloud networkand the fourth VPC 440 includes a second set of transit gateways 445.The second set of transit gateways 445 may correspond to VNets operatingwithin the Microsoft® Azure® cloud network being the second public cloudnetwork 404. Stated generally, the second cloud network 404 correspondsto any public cloud network different than the first public cloudnetwork 402 (e.g., Google® Cloud, Microsoft® Azure®, etc. when the firstpublic cloud network 402 is AWS) and the second set of transit gateways445 constitutes any type of resources that effectuate data transfer withthe first set of transit gateways 435.

Similar in architecture of the multi-cloud computing platform 100described in FIG. 1, each spoke gateway of the first set spoke gateways415 is communicatively coupled to each transit gateway of the first setof transit gateways 435 through IPSec tunnels 450 ₁₁, 450 ₁₂, 450 ₂₁,450 ₂₂, 450 ₃₁ and 450 ₃₂ in a crisscross scheme. Additionally, each ofthe spoke gateways 415 is communicatively coupled together via GREtunnels 455 ₁-455 ₃.

As further shown in FIG. 4, each transit gateway of the first set oftransit gateways 435 is communicatively coupled to each spoke gateway ofthe first set of spoke gateways 415 through IPSec tunnels 450 ₁₁-450 ₃₂as described above. Additionally, each of the first set of transitgateways 435 deployed within the third VPC 430 is communicativelycoupled to (i) the on-prem computing devices 180 within the on-premisesnetwork 190 (e.g., on-prem computing devices 180 ₁ and 180 ₂) via IPSectunnels 460 ₁₁, 460 ₁₂, 460 ₂₁ and 460 ₂₂ and (ii) each transit gatewayof the second set of transit gateways 445 deployed within the fourth VPC440 being part of the second public cloud network 404 via IPSec tunnels470 ₁₁, 470 ₁₂, 470 ₂₁ and 470 ₂₂. The second set of transit gateways445 is communicatively coupled to the second set of spoke gateways 425(e.g., corresponding to spoke VNets for Microsoft® Azure® deployment)via IPSec tunnels 480 ₁₁, 480 ₁₂, 480 ₂₁ and 480 ₂₂.

As further shown in FIG. 4, each of the gateways with the VPCs may becommunicatively coupled together via GRE tunnels to avoid VPC routingtable reprogramming upon failure of IPSec tunnels associated with aparticular gateway. In particular, each of the first set of spokegateways 415 is communicatively coupled together via GRE tunnels 455₁-455 ₃. Similarly, each of the first set of transit gateways 435 iscommunicatively coupled together via GRE tunnel 465 while each of thesecond set of spoke gateways 435 and the second set of transit gateways445 is communicatively coupled together via GRE tunnel 475 and GREtunnels 485, respectively.

It is contemplated that two or more of the VPCs 410, 420, 430 and 445may reside in different public cloud networks. For instance, accordingto one embodiment of the disclosure, each of the VPCs 410, 420, 430 and445 may be deployed in a different public cloud network than any of theother VPCs. According to another embodiment of the disclosure, at leasttwo of the VPCs 410, 420, 430 and 445 may be deployed within one type ofpublic cloud network and at least one of the remaining VPCs 410, 420,430 and 445 may be deployed within another type of public cloud network.

The communications between the second VPC 420 and the fourth VPC 440provide a reliable communication scheme among multiple VPCs featuringspoke gateways that enable a user to access cloud instances with thefirst VPC 410 via the first set of spoke gateways 415 and the second VPC420 via the second set of spoke gateways 425. Also, when multiple VPCsare deployed and support inter-communications, this spoke-hub architecthas advantage over full meshed direct peering between VPCs—it is morecost effective (e.g., less peering connections needed; lower requirementfor VPC gateway resources, etc.), easier manageability, and the like.

III. Operational Flow

Referring now to FIG. 5, a flowchart of an exemplary embodiment of theoperability of the public cloud computing platform of FIG. 1 insupporting communications between multiple virtual private cloudnetworks (VPCs) that are designed to mitigate the necessity ofreprogramming VPC routing table(s) based on communication link failuresexperienced by gateways within the VPC. Herein, according to oneembodiment of the disclosure, the controller collects VPC information asdescribed above (block 500). Thereafter, for the public cloud computingplatform illustrated in FIG. 1 for example, the controller configures afirst VPC routing table to identify (i) which instance subnet maintainedwithin the first (spoke) VPC corresponds to which gateway and (ii) whichgateways of the first VPC are in communication with which gateways ofthe second (transit) VPC (block 510).

Additionally, the controller may initially configure each of the gatewayrouting tables to create mesh-style, peer-to-peer communication linksbetween remote gateways such as spoke-transit gateways implemented ondifferent VPCs (e.g., IPSec tunnels) as well as communications betweentransit gateways and computing devices (e.g., routers) of theon-premises network (block 520). For load balancing, each of thecommunication links, represented as routing paths, may be configuredwith multi-path (ECMP) routing parameters (e.g., identical routingweights and ECMP metrics) to ensure that sources may rely on the routingpaths equally. Additionally, these gateway routing tables may includepeer-to-peer communications (secondary tunnels) between spoke gatewaysor transit gateways within the same VPC (block 530). As a result, theVPC routing table and gateway routing tables specific to each gatewayare generated, where the gateway routing tables are now responsible foralternating its gateway routing table to address state channels withinthe IPSec tunnels and GRE tunnels.

In response to a communication path failure, such as an IPSec tunnelbecomes disabled for example, the spoke or transit gateway associatedwith the failed IPSec tunnel disables the communication link (routingpath) by altering the VTI state within an entry associated with thedisabled IPSec tunnel (blocks 540 and 550; FIGS. 6A-6B). Thereafter, thegateway determines whether all IPSec tunnels from the gateway directedto next hop have become disabled (block 560). If not, a different IPSectunnel available to the gateway is used (block 565). If so, the gatewayutilizes the secondary tunnel as a route for data traffic to the nexthop via another gateway (block 570; FIG. 6C). This process continuesuntil one of the IPSec tunnels returns to an active state. In themeantime, the gateways monitor whether the failed IPSec tunnel isreturned to “active” status (block 580). If so, the gateway recovers thefailed IPSec tunnel by returning the IPSec tunnel to the gateway routingtable upon returning the VTI state to “active” status and gracefullydiscontinuing routing over the secondary tunnel (block 590), where IPSectunnel status is continued to be monitored.

Embodiments of the invention may be embodied in other specific formswithout departing from the spirit of the present disclosure. Thedescribed embodiments are to be considered in all respects only asillustrative, not restrictive. The scope of the embodiments is,therefore, indicated by the appended claims rather than by the foregoingdescription. All changes that come within the meaning and range ofequivalency of the claims are to be embraced within their scope.

What is claimed is:
 1. A computerized method, comprising: generating afirst virtual private cloud network including a first plurality ofgateways, the first virtual private cloud network being deployed withina first public cloud network and each gateway of the first plurality ofgateways is in communication with one or more other gateways of thefirst plurality of gateways over one or more communication links;generating a second virtual private cloud network including a secondplurality of gateways, the second virtual private cloud network beingdeployed within a second public cloud network different than the firstpublic cloud network, each of the second plurality of gateways beingcommunicatively coupled to each of the first plurality of gateways overpeer-to-peer communication links to enable communications between thefirst virtual private cloud network operating within the first publiccloud network and the second virtual private cloud network operatingwithin the second public cloud network; responsive to a peer-to-peercommunication link of the peer-to-peer communication links failing,autonomously updating a gateway routing table associated with a gatewayof the first plurality of gateways by disabling a virtual tunnelinterface corresponding to the failed peer-to-peer communication linkwithout reliance on activity by a controller that manages operability ofa network including the first virtual private cloud network and thesecond virtual private cloud network.
 2. The computerized method ofclaim 1, wherein a communication link of the one or more communicationlinks is active when no peer-to-peer communication links communicativelycoupled to the first gateway of the first plurality of gateways isactive.
 3. The computerized method of claim 1, wherein the peer-to-peercommunication links operate in accordance with an Internet ProtocolSecurity (IPSec) protocol.
 4. The computerized method of claim 1,wherein each of the peer-to-peer communication links is set toidentical, equal cost multi-path (ECMP) routing metrics to achieveload-balancing.
 5. The computerized method of claim 4, wherein each ofthe one or more communication links is assigned a lower ECMP routingmetric than any ECMP routing metric assigned to a peer-to-peercommunication link of the peer-to-peer communication links.
 6. Thecomputerized method of claim 1, wherein each of the peer-to-peercommunication links is assigned a different routing weight to achieveload-balancing, the weight being based on bandwidth capacity.
 7. Anetwork system comprising: a first virtual private cloud networkincluding a first plurality of gateways, the first virtual private cloudnetwork being deployed within a first public cloud network and eachgateway of the first plurality of gateways is in communication with oneor more other gateways of the first plurality of gateways over one ormore communication links; and a second virtual private cloud networkincluding a second plurality of gateways, the second virtual privatecloud network being deployed within a second public cloud networkdifferent than the first public cloud network, each of the secondplurality of gateways being communicatively coupled to each of the firstplurality of gateways over peer-to-peer communication links to enablecommunications between the first virtual private cloud network operatingwithin the first public cloud network and the second virtual privatecloud network operating within the second public cloud network, whereinresponsive to a peer-to-peer communication link of the peer-to-peercommunication links failing, a gateway of the first plurality ofgateways updates a gateway routing table autonomously by disabling avirtual tunnel interface corresponding to the failed peer-to-peercommunication link without reliance on activity by a controller thatmanages operability of a network including the peer-to-peercommunication links.
 8. The network system of claim 7, wherein a firstgateway of the first plurality of gateways being in communication withat least a second gateway of the first plurality of gateways over acommunication link of the one or more communication links operating inaccordance with a Generic Routing Encapsulation (GRE) tunnel protocol tosecure communications between each of the first plurality of gatewaysfor subsequent communication to one of the second plurality of gateways.9. The network system of claim 7, wherein each of the first plurality ofgateways and the second plurality of gateways correspond to a virtualmachine (VM)-based data routing component, each of the first pluralityof gateways is assigned a Private Internet Protocol (IP) address withinan IP address range associated with the first virtual private cloudnetwork and each of the second plurality of gateways is assigned aPrivate IP address within an IP address range associated with the secondvirtual private cloud network different than the first virtual privatecloud network.
 10. The network system of claim 7, wherein thecommunication link of the one or more communication links is active whenno peer-to-peer communication links communicatively coupled to the firstgateway of the first plurality of gateways is active.
 11. The networksystem of claim 7, wherein the peer-to-peer communication links operatein accordance with an Internet Protocol Security (IPSec) protocol. 12.The network system of claim 7, wherein each of the peer-to-peercommunication links is set to identical, equal cost multi-path (ECMP)routing metrics to achieve load-balancing.
 13. The network system ofclaim 12, wherein each of the one or more communication links isassigned a lower ECMP routing metric than any ECMP routing metricassigned to a peer-to-peer communication link of the peer-to-peercommunication links.
 14. The network system of claim 7, wherein each ofthe peer-to-peer communication links is assigned a different routingweight to achieve load-balancing, the weight being based on bandwidthcapacity.
 15. The network system of claim 7, wherein the gateway of thefirst plurality of gateways precludes messages from being routed throughthe failed peer-to-peer communication link to mitigate data transmissionloss by at least relying on a routing of messages through a secondpeer-to-peer communication link assigned to communicate with an instancethat previously utilized the failed peer-to-peer communication link. 16.The network system of claim 7, wherein the first plurality of gatewaysoperate as transit gateways deployed within a first region of the firstpublic cloud network and the second plurality of gateways operate astransit gateways deployed within a second region of the second publiccloud network.
 17. The network system of claim 16, wherein the secondplurality of gateways operating as a transit virtual networks.
 18. Thenetwork system of claim 16 further comprises a third virtual privatecloud network including a plurality of spoke gateways, each of theplurality of spoke gateways being communicatively coupled to each of thefirst plurality of gateways via peer-to-peer communication links, thethird virtual private cloud network being deployed within the firstpublic cloud network.
 19. The network system of claim 16 furthercomprises a third virtual private cloud network including a plurality ofspoke gateways, each of the plurality of spoke gateways beingcommunicatively coupled to each of the first plurality of gateways viapeer-to-peer communication links, the third virtual private cloudnetwork being deployed within either the second public cloud network ora public cloud network different than the first public cloud network.20. A non-transitory storage medium including software that, uponexecution, performs operations comprising: establishing a firstplurality of gateways as part of a first virtual private cloud networkoperating within a first public cloud network infrastructure;establishing a second plurality of gateways as part of a second virtualprivate cloud network operating within a second public cloud networkinfrastructure; configuring the first plurality of gateways to be incommunications with the second plurality of gateways over peer-to-peercommunication links, wherein each gateway of the first plurality ofgateways supports multiple, active peer-to-peer communication links todifferent gateways of the second plurality of gateways to enablecommunications between the first virtual private cloud network operatingwithin the first public cloud network infrastructure and the secondvirtual private cloud network operating within the second public cloudnetwork infrastructure; and responsive to a peer-to-peer communicationlink of the peer-to-peer communication links failing, a gateway of thefirst plurality of gateways updates a gateway routing table autonomouslyby disabling a virtual tunnel interface corresponding to the failedpeer-to-peer communication link without reliance on activity by acontroller that manages operability of a network including thepeer-to-peer communication links.
 21. The non-transitory storage mediumof claim 20, wherein each of the peer-to-peer communication links isestablished by the software and corresponds to an Internet ProtocolSecurity (IPSec) tunnel.
 22. The non-transitory storage medium of claim20, wherein the first plurality of gateways operate as transit gatewaysdeployed to operate as part of the first public cloud network and thesecond plurality of gateways operate as transit gateways deployed tooperate as part of the second public cloud network that is differentthan the first public cloud network.
 23. The non-transitory storagemedium of claim 20, wherein the software configuring the peer-to-peercommunication links to support communications between the firstplurality of gateways and the second plurality of gateways, thepeer-to-peer communication links include a plurality of communicationlinks that are active concurrently to achieve load balancing.
 24. Thenon-transitory storage medium of claim 20, wherein the first publiccloud network infrastructure is associated with a first public cloudnetwork provided by a first cloud service provider that is differentfrom a second public cloud network associated with the second publiccloud network infrastructure provided by a second cloud service providerdifferent from the first cloud service provider.
 25. The non-transitorystorage medium of claim 20, wherein the first public cloud networkcorresponding to an Amazon Web Services cloud network.
 26. Thenon-transitory storage medium of claim 20, wherein the first publiccloud network infrastructure is associated with a first region of apublic cloud network provided by a cloud service provider that isdifferent from a second public cloud network associated with a secondregion of the public cloud network.